Digital Design Flow Introduction

We have seen in the short introduction to the DDS lecture that we want to take interest in Complex Digital Systems.

In this first lecture, we will try to set the foundations to understand how digital systems are build, and define which criterias should be looked at to understand them:

  • Specification
    • Hierarchy
    • Input and Output data
    • Synchronicity sources
  • Verification
    • Relation between Simulation and Specification
  • Physical Implementation
    • Target technology mapping

Those few criterias should be sufficient to both find the entry points in existing designs, and to know where to start when starting a new project. The work in the lab and the next lectures will detail those various themes, but the idea is to come back to this introduction

This list of concepts can be read from top to bottom, and brings us from the Specification of a System to its physical realisation. This process is generally called a Design Flow, and we are going to introduce those points in a concise way in this part of the lecture.

Global Definition of a System

A system, by definition, is a set of components in relation with each other.

A digital system is by extension a set of components organised to accomplish a set of specific tasks on digital data.

Because a digital system is also a concrete entity, which can be interacted with, it is usually first described by a set of input and related outputs:

../../_images/system1.png

The most common system we all know about is the microprocessor, which is a programmable system, meaning it has no purpose of its own other than performing the tasks programmed by the user.

Microprocessors are the common building blocks of Embedded Systems, like computers, phones, tablets etc…

Embedded Systems Input and Outputs are typically interfaces to:

  • Communication devices:
    • Ethernet Physical Interface
    • Wireless Communication ASIC : WLAN, Bluetoooth, Zigbee etc…
  • Human Interfaces:
    • Keyboard, Mouse
    • Screen
    • Audio Codec
  • Sensors:
    • Camera
    • Accelerometer
    • GPS

From there one, we can already sense that besides Input/Output interconnection, the components of a system are bound by a logical order. Some components may be dedicated to communication while others to human interaction, therefore they can logically be grouped by function.

The Logical grouping and ordering withing a System is refered to as the Hierarchy. The Hierarchy is essential to the designer for a few reasons:

  • It allows a human representation of components relations.
  • It is the first concept encountered when studying a system or creating one, a hierarchy-less system cannot be build.
  • Careful Hierarchy Planing can greatly optimise a design’s implementation by enabling easy splitting of the job (Verification, Physical implementation etc…)

Just to give a simple trivial example, the following picture represents a little hierarchy for a Phone device We have represented the structure of the device using two kinds of drawings:

  • Blocks connected by arrows would denote container-containee relations of physical components (Phone contains CPU/GPU)
  • An Enclosing block would represent a logical grouping of devices, like the radio devices belonging to a communication group.
../../_images/hierarchy.png

Example of a hierarchy drawing for a phone

Note that hierarchies are thus not necessarily related to actual physical logic functions, but really to logical function relations.

Synchronous Logic Systems and Pipelining

Before studying the actual implementation of a system, we want to introduce or remind about the concept of synchronous logic, and it’s pendant the synchronous Pipeline.

This subject is related to the actual circuit implementation, but is central to the specification, and has an impact on all the levels of the design flow. It is also the source of major headaches when analysing simulation results.

Synchronous or Sequential Logic describes a logic circuit which is broken down into small logic processing units, or sub-circuit, which results are stored in memory elements updated by a clock, like Flip Flops, and made available for the next unit, while the processing repeats.

Each of these units is called a “Pipeline Stage”, because each of them uses the results of the previous circuits, and passes its own to the next, as if data would go through a Pipeline.

A Pipeline stage is usually drawn using three elements, like in following picture:

  • The Start Flip-Flop(s), which is the memory storing the results of the previous stage
  • The Logic “Cloud”, which is the set of logic gates performing the operation on the data for the current stage.
  • The End Flip-Flop(s), which is the memory storing the results of the logic
  • The Clock Period defines the time allowed for the logic Cloud’s Delay.
../../_images/pstage.png

Note that we describe Pipeline Stages using singular, because usually we have to look at single bits or wire during physical implementation, but the Pipeline Stages can process wide data busses and thus be driving multiple Flip-Flops.

If you have studied microprocessor architecture, you have heard about the Pipeline before. The Microprocessor Processing Pipeline is typically roughly mapped to the supported instructions, as we can see on the following picture taken from Wikipedia:

System Specification

Now that we have defined a System by it’s components, their hierarchial ordering and interconnections through input and outputs, we know we can write down a specification which would be intelligible for humans.

However, we haven’t talked about the actual digital circuit definition. Knowing Input and Outputs is a first step to create a circuit, because then we know how to interact with it, but it doesn’t define the actual behaviour of the circuit like:

  • How does it perform it’s task?
  • How fast is it?
  • How much space does it need?
  • How much energy will it need?
../../_images/system-spec.png

Parent Hierarchy, containing an unspecified circuit.

As we have mentionned before, we are interested in Semi Custom circuits, meaning we won’t be drawing the circuit logical gate by logical gate. Also, it would be rather unpleasant to keep the system Specification in a text form, and implement our circuits in very different formats.

In digital systems, we therefore can use a Hardware Description Language (HDL), which resembles a common programming language, and allows us to describe our system’s components, including hierarchy, interconnections and circuitry. This abstract language representation can be read by tools, which can for example perform simulation or circuit synthesis to real logic gates.

There are two major hardware description languages:

  • Verilog, Mostly Used in the US
  • VHDL, Mostly used in Europe

In the lecture and Lab we will teach Verilog, because it more lightweight than VHDL. However, The basic concepts about System Specifications are covered by both languages in a similar way.

Verification

Verification is a key step in a system design. It is generally refered to as Simulation, but the two terms bear a slightly different meaning:

  • Simulation covers all the methods available to simulate the behavior of a system.

It includes for example special programming environments and language features available to a specific simulator (Randomisation, Simulator Interface, Coverage etc…).

  • Verification covers the strategy employed to verify the correcteness of a system.

The verification environment is usually defined by the simulation methods employed to verify the system. In the end it takes the form of a software which uses simulation to test the System.

../../_images/verification.png

System is tested in a Verification Environment running in a simulator

Nice Hierarchy!

As one can understand, the Verification step is critical, as Silicon device production is long and expensive. Any error in a design can represent large costs in terms of manpower and market share loss.

../../_images/donald.jpg

Errors in Systems should be avoided

Technology Mapping

If we are confident a system has enough features to be actually used physically, we can move to Technology Mapping. This step is very similar when producing a Silicon Device, or when using a configurable device like an FPGA.

The major difference between an ASIC and an FPGA must be covered right away. Technology mapping in FPGA follows the same steps as in ASIC, but happens in a more constrained environment. Indeed, FPGAs have a lot of ready to use resources which can be used, like:

  • RAM memory
  • Communication Devices
  • PLL for clock multipliers and dividers etc…

As we are interested in ASIC design here, we have to imagine we are starting from scratch. This means that we will have to first choose a target technology (65nm, 40nm, 28nm etc…), based on various criterias like:

  • Desired Speed: Smaller is faster
  • Costs: Smaller is more expensive
  • Available Resources: Memory, PLL etc… must I build them, or can they be bought?

Once we have a chosen a technology, a set of tools will translate the Hardware Specification to physical logical gates, and ensure correctness. This process takes place in two main steps:

  • Physical Synthesis translates the HDL to a network of Logic gates containing the design’s transitors (AND, OR etc…).
  • Place And Route (P&R) places the logic gates on a defined area and routes the wire connections.
../../_images/techmap.png

Very Simplified Physical Flow. From Code to Wired Logic Gates.

These steps will be detailed later during the semester, but for now these are the general concepts to keep in mind.